…=petrochenkov,jieyouxu

Cleanup sysroot locating a bit

All commits should preserve existing behavior.

…=petrochenkov,jieyouxu

Cleanup sysroot locating a bit

All commits should preserve existing behavior.

…iaskrgr

Rollup of 7 pull requests

Successful merges:

 - rust-lang#137816 (attempt to support `BinaryFormat::Xcoff` in `naked_asm!`)
 - rust-lang#138109 (make precise capturing args in rustdoc Json typed)
 - rust-lang#138343 (Enable `f16` tests for `powf`)
 - rust-lang#138356 (bump libc to 0.2.171 to fix xous)
 - rust-lang#138371 (Update compiletest's `has_asm_support` to match rustc)
 - rust-lang#138380 (ci: add runners for vanilla LLVM 20)
 - rust-lang#138404 (Cleanup sysroot locating a bit)

r? `@ghost`
`@rustbot` modify labels: rollup

…iaskrgr

Rollup of 6 pull requests

Successful merges:

 - rust-lang#137816 (attempt to support `BinaryFormat::Xcoff` in `naked_asm!`)
 - rust-lang#138109 (make precise capturing args in rustdoc Json typed)
 - rust-lang#138343 (Enable `f16` tests for `powf`)
 - rust-lang#138356 (bump libc to 0.2.171 to fix xous)
 - rust-lang#138371 (Update compiletest's `has_asm_support` to match rustc)
 - rust-lang#138404 (Cleanup sysroot locating a bit)

r? `@ghost`
`@rustbot` modify labels: rollup

Rollup merge of rust-lang#138404 - bjorn3:sysroot_handling_cleanup, r=petrochenkov,jieyouxu

Cleanup sysroot locating a bit

All commits should preserve existing behavior.

…iaskrgr

Rollup of 6 pull requests

Successful merges:

 - rust-lang#137816 (attempt to support `BinaryFormat::Xcoff` in `naked_asm!`)
 - rust-lang#138109 (make precise capturing args in rustdoc Json typed)
 - rust-lang#138343 (Enable `f16` tests for `powf`)
 - rust-lang#138356 (bump libc to 0.2.171 to fix xous)
 - rust-lang#138371 (Update compiletest's `has_asm_support` to match rustc)
 - rust-lang#138404 (Cleanup sysroot locating a bit)

r? `@ghost`
`@rustbot` modify labels: rollup

…r=petrochenkov

Replace all uses of sysroot_candidates with get_or_default_sysroot

Before this change we had two different ways to attempt to locate the sysroot which are inconsistently used:
* `get_or_default_sysroot` which tries to locate based on the 0th cli argument and if that doesn't work falls back to locating it using the librustc_driver.so location and returns a single path.,
* `sysroot_candidates` which takes the former and additionally does another attempt at locating using `librustc_driver.so` except without linux multiarch handling and then returns both paths.,

The latter was originally introduced to be able to locate the codegen backend back when cg_llvm was dynamically linked even for a custom driver when the `--sysroot` passed in does not contain a copy of cg_llvm. Back then `get_or_default_sysroot` did not attempt to locate the sysroot based on the location of librustc_driver.so yet. Because that is now done, the only case where removing `sysroot_candidates` can break things is if you have a custom driver inside what looks like a sysroot including the `lib/rustlib` directory, but which is missing some parts of the full sysroot like eg rust-lld.

Follow up to rust-lang#138404

…r=petrochenkov

Replace all uses of sysroot_candidates with get_or_default_sysroot

Before this change we had two different ways to attempt to locate the sysroot which are inconsistently used:
* `get_or_default_sysroot` which tries to locate based on the 0th cli argument and if that doesn't work falls back to locating it using the librustc_driver.so location and returns a single path.,
* `sysroot_candidates` which takes the former and additionally does another attempt at locating using `librustc_driver.so` except without linux multiarch handling and then returns both paths.,

The latter was originally introduced to be able to locate the codegen backend back when cg_llvm was dynamically linked even for a custom driver when the `--sysroot` passed in does not contain a copy of cg_llvm. Back then `get_or_default_sysroot` did not attempt to locate the sysroot based on the location of librustc_driver.so yet. Because that is now done, the only case where removing `sysroot_candidates` can break things is if you have a custom driver inside what looks like a sysroot including the `lib/rustlib` directory, but which is missing some parts of the full sysroot like eg rust-lld.

Follow up to rust-lang#138404

…r=petrochenkov

Replace all uses of sysroot_candidates with get_or_default_sysroot

Before this change we had two different ways to attempt to locate the sysroot which are inconsistently used:
* `get_or_default_sysroot` which tries to locate based on the 0th cli argument and if that doesn't work falls back to locating it using the librustc_driver.so location and returns a single path.,
* `sysroot_candidates` which takes the former and additionally does another attempt at locating using `librustc_driver.so` except without linux multiarch handling and then returns both paths.,

The latter was originally introduced to be able to locate the codegen backend back when cg_llvm was dynamically linked even for a custom driver when the `--sysroot` passed in does not contain a copy of cg_llvm. Back then `get_or_default_sysroot` did not attempt to locate the sysroot based on the location of librustc_driver.so yet. Because that is now done, the only case where removing `sysroot_candidates` can break things is if you have a custom driver inside what looks like a sysroot including the `lib/rustlib` directory, but which is missing some parts of the full sysroot like eg rust-lld.

Follow up to rust-lang#138404

Rollup merge of #142089 - bjorn3:sysroot_handling_cleanup3, r=petrochenkov

Replace all uses of sysroot_candidates with get_or_default_sysroot

Before this change we had two different ways to attempt to locate the sysroot which are inconsistently used:
* `get_or_default_sysroot` which tries to locate based on the 0th cli argument and if that doesn't work falls back to locating it using the librustc_driver.so location and returns a single path.,
* `sysroot_candidates` which takes the former and additionally does another attempt at locating using `librustc_driver.so` except without linux multiarch handling and then returns both paths.,

The latter was originally introduced to be able to locate the codegen backend back when cg_llvm was dynamically linked even for a custom driver when the `--sysroot` passed in does not contain a copy of cg_llvm. Back then `get_or_default_sysroot` did not attempt to locate the sysroot based on the location of librustc_driver.so yet. Because that is now done, the only case where removing `sysroot_candidates` can break things is if you have a custom driver inside what looks like a sysroot including the `lib/rustlib` directory, but which is missing some parts of the full sysroot like eg rust-lld.

Follow up to #138404

…enkov

Replace all uses of sysroot_candidates with get_or_default_sysroot

Before this change we had two different ways to attempt to locate the sysroot which are inconsistently used:
* `get_or_default_sysroot` which tries to locate based on the 0th cli argument and if that doesn't work falls back to locating it using the librustc_driver.so location and returns a single path.,
* `sysroot_candidates` which takes the former and additionally does another attempt at locating using `librustc_driver.so` except without linux multiarch handling and then returns both paths.,

The latter was originally introduced to be able to locate the codegen backend back when cg_llvm was dynamically linked even for a custom driver when the `--sysroot` passed in does not contain a copy of cg_llvm. Back then `get_or_default_sysroot` did not attempt to locate the sysroot based on the location of librustc_driver.so yet. Because that is now done, the only case where removing `sysroot_candidates` can break things is if you have a custom driver inside what looks like a sysroot including the `lib/rustlib` directory, but which is missing some parts of the full sysroot like eg rust-lld.

Follow up to rust-lang/rust#138404